An important aspect of trusted computing is to ensure that software running on a computer is not modified from a version, known (or at least believed) to be safe. The reason for this is that malware often acts by modifying an existing application (e.g. an executable file) and performs malicious acts whenever the modified application is executed (such modification may be either a complete replacement of the legitimate code, an addition to the legitimate code or a partial replacement of some of the code). In order to detect if an application residing on a computer has been modified, a Trusted Platform Module (TPM) stores a hash of all programmes when they are in a state where they are trusted to be clean (i.e. without having any malware code incorporated in any way in the application), this may typically be when they are first loaded onto a system. If one of these applications subsequently becomes infected by a piece of malware, it will necessarily be modified and the hash generated from the modified program will no longer match the stored hash.
In view of the above, a known strategy by which a TPM may detect a potentially suspicious modification is to generate a new hash value for each program (e.g. an executable application, an executable file, a library of functions, a component etc.) whenever it is to be launched and to compare this with a pre-stored hash value (stored in a “white-list” of safe hash values for trusted programs) which is supposed to correspond to the program. If the hash values do not match, the TPM concludes that the software has been modified from the trusted version and could therefore potentially be unsafe, whereupon the computer (system) may take an appropriate course of action (e.g. it may prevent the program from running or from having access to certain resources—such as external network access or write access to a storage device, etc.).
A difficulty with the above described strategy is dealing with legitimate modifications to a program (e.g. to update a complex application). One known prior art approach to address the requirement for legitimate applications to update themselves (from time to time) is to provide a large comprehensive “whitelist library” of acceptable hashes of applications (of many different “versions”). Such a library should be provided and maintained by a trusted third party. If a program is updated to a new version (e.g. from version 5.2 to version 5.3 or to version 6.0 etc.), the TPM can generate a hash code for the updated program and then compare the generated hash code with the comprehensive library containing all acceptable hash codes for legitimate applications maintained by the trusted third party. Only if the generated hash code can be found in the white list library will the modified application be deemed to be trusted.
EP 1 887 731 describes a variant on the above described standard approach in which programs are divided up into smaller chunks each of which has its own associated hash. When a program needs to be updated only the changed chunks are downloaded and replace the corresponding existing chunks. Each of the chunks is then hashed and the locally generated hashes are compared with hashes form the remote trusted server in the normal way.
Problems with this type of approach include the need to have network access to a suitable trusted third party, the complexity of maintaining the external whitelist (and the need for all software producers to deal with a trusted third party maintainer (and possibly several if trusted third parties compete with one another) of the external whitelist library or libraries), the need for a secure connection to be made to a suitable trusted third party and for the trusted third party to be properly authenticated to prevent malicious users from masquerading as a trusted third party, etc. A further problem is a potential delay in being able to use the newly updated application until its newly updated hash has been verified as legitimate, etc. which may take time if no suitable network access is available or if there is a shortage of other necessary resources for this process (e.g. processing power—cryptographic processing power etc.) as might occur where the device in question is a mobile device.